I am not fully satisfied here, especially because AMSMessage currently introduces a memory leak if it not used properly. In our case, because of the shared_ptr, the memory is freed. But if you use AMSMessage to create a temporary message, for example:

void foo() {
  AMSMessage msg (...);
  // code here...
} // msg._data is not freed here

But if you create a shared_ptr you are good:

void foo() {
  AMSMessage msg (...);
  std::shared_ptr<uint8_t> ptr(msg.data());
} // msg._data is freed here

However, it is counterintuitive and not RAII. Ideally, msg._data would be smart pointer from the beginning.

@lpottier I further extended your logic. We now have a persistent map of unAck messages. This is implemented as a singleton. All threads can be aware at any time about these messages. It removes some of our logic in passing the AMSMessageRecords around.

I also fixed the data race I pointed out earlier.

I am not fully satisfied here, especially because AMSMessage currently introduces a memory leak if it not used properly. In our case, because of the shared_ptr, the memory is freed. But if you use AMSMessage to create a temporary message, for example:

void foo() {
  AMSMessage msg (...);
  // code here...
} // msg._data is not freed here

But if you create a shared_ptr you are good:

void foo() {
  AMSMessage msg (...);
  std::shared_ptr<uint8_t> ptr(msg.data());
} // msg._data is freed here

However, it is counterintuitive and not RAII. Ideally, msg._data would be smart pointer from the beginning.

This is valid. We should at some point fix this. Not in this PR as it sounds orthogonal. Can you post an issue?